Deep Linking, Navigation Guards, and Authentication-Based Routing in React Native

Course: React Native Training

Topic: Deep Linking, Navigation Guards, and Authentication-Based Routing

Course Link: React Native Training at JustAcademy

Demo Registration: Register for a Free Course Demo

JustAcademy Website: Visit JustAcademy

1. Introduction

Navigation is an essential part of a React Native application because users need to move between screens, access specific content, and complete tasks. In a real-world application, navigation must also support links from external websites, protect private screens, and display different routes depending on whether a user is authenticated.

Deep linking, navigation guards, and authentication-based routing work together to create a secure and convenient navigation experience.

• Deep Linking: Opens a particular screen in an application through a URL or external link.
• Navigation Guards: Apply rules that determine whether a user can access a particular screen or route.
• Authentication-Based Routing: Displays authentication screens or application screens according to the user's login state.

For example, an e-commerce application may open a product details screen when a customer taps a product link. If the customer tries to access their order history without logging in, the application should show the login screen first.

2. Learning Objectives

After completing this topic, learners will be able to:

• Understand deep linking and its role in mobile applications.
• Configure URL prefixes and screen paths in React Navigation.
• Handle custom URL schemes and HTTPS links.
• Understand the difference between authentication and authorization.
• Implement protected screens using conditional navigation.
• Build login and logout flows.
• Manage loading states while restoring an existing session.
• Handle links that point to protected screens.
• Understand route validation, role-based access, and common security mistakes.
• Test navigation flows on Android, iOS, and development environments.

3. Understanding React Native Navigation

3.1 What Is Navigation?

Navigation is the process of moving between different screens in an application. React Native applications commonly use React Navigation to manage stacks, tabs, drawers, route parameters, and linking.

Typical application screens include:

• Home Screen
• Login Screen
• Registration Screen
• Product Details Screen
• User Profile Screen
• Order History Screen
• Settings Screen

3.2 Installing React Navigation

For a project using React Navigation's native stack navigator, install the required packages using the commands recommended for your React Native version and project setup.

npm install @react-navigation/native
npm install @react-navigation/native-stack

For a standard React Native CLI project, the navigation dependencies may also require native packages such as the following:

npm install react-native-screens react-native-safe-area-context

Follow the official installation instructions because native setup requirements can vary by platform and project configuration.

Official documentation: React Navigation Getting Started

4. Understanding Deep Linking

4.1 What Is Deep Linking?

Deep linking allows an application to open a specific screen using a URL instead of requiring the user to open the application and navigate manually.

For example, a product link might look like this:

myapp://products/101

When configured correctly, this URL can open the application and display the product with ID 101.

An HTTPS link might look like this:

https://app.example.com/products/101

The application can be configured to handle this URL when the appropriate platform and domain association settings are in place.

4.2 Why Deep Linking Is Important

• Direct access: Users can open a specific screen without navigating from the home screen.
• Marketing campaigns: Campaign links can open a relevant product, promotion, or landing screen.
• Notifications: Tapping a notification can direct users to related content.
• Sharing: Users can share links to products, articles, profiles, and other resources.
• User experience: Deep links reduce the number of steps required to reach content.
• Web-to-app journeys: Website links can direct users to equivalent screens in a mobile application.

4.3 Types of Deep Links

Custom schemes are relatively straightforward to configure, but they do not provide the same verified domain ownership mechanism as Universal Links and Android App Links. A custom scheme can also conflict with another application using the same scheme.

5. Configuring Deep Linking in React Navigation

5.1 Define the URL Scheme

For an Expo application, a custom scheme can be defined in the application configuration.

{
  "expo": {
    "scheme": "myapp"
  }
}

The scheme allows links such as myapp://products/101 to identify the application. Depending on the development environment, Expo development URLs may use a different prefix. For Expo projects, use the appropriate linking prefix helper.

5.2 Define a Linking Configuration

The following example uses a dynamic React Navigation configuration with a native stack navigator. It maps URL paths to screen names and route parameters.

import React from 'react';
import { Text } from 'react-native';
import { NavigationContainer } from '@react-navigation/native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';

import HomeScreen from './screens/HomeScreen';
import ProductDetailsScreen from './screens/ProductDetailsScreen';
import ProfileScreen from './screens/ProfileScreen';

const Stack = createNativeStackNavigator();

const linking = {
  prefixes: [
    'myapp://',
    'https://app.example.com'
  ],
  config: {
    screens: {
      Home: '',
      ProductDetails: 'products/:productId',
      Profile: 'profile'
    }
  }
};

export default function App() {
  return (
    Loading navigation...}
    >
      
        
        
        
      
    
  );
}

In this configuration, the product URL is mapped to the ProductDetails screen. The URL segment after products/ becomes the productId route parameter.

5.3 Read Deep Link Parameters

When a deep link opens a configured screen, the screen can read the parsed parameters through the route object.

import React from 'react';
import { View, Text } from 'react-native';

export default function ProductDetailsScreen({ route }) {
  const { productId } = route.params ?? {};

  return (
    
      Product Details
      Product ID: {productId ?? 'Not provided'}
    
  );
}

Always validate route parameters before using them to fetch data. A deep link is external input and should not be treated as trusted application data.

5.4 How Deep Linking Works

1. A user taps a URL or opens a link from another application.
2. The operating system determines whether an installed application can handle the URL.
3. The application receives the URL through the native linking integration.
4. React Navigation matches the URL against its configured prefixes and paths.
5. The matching route is selected and URL parameters are parsed.
6. The destination screen validates the parameters and loads the required data.

5.5 Cold Start and Warm Start

Deep links must work in two situations:

• Cold start: The application is not running and must start from the incoming URL.
• Warm start: The application is already running and must process a new incoming URL.

React Navigation's linking integration handles these cases when configured correctly. Avoid building a separate manual routing mechanism unless your requirements specifically demand it.

6. Custom URL Schemes and HTTPS Links

6.1 Custom URL Scheme

A custom scheme uses an application-defined prefix.

myapp://products/101
myapp://profile
myapp://settings

Advantages include simple route examples and easy testing. However, a custom scheme is not proof that a URL originated from a trusted sender, and other applications may register a matching scheme.

6.2 Universal Links and Android App Links

Universal Links on iOS and verified Android App Links use HTTPS domains associated with the application. These require native configuration and domain verification files.

Common setup requirements include:

• Configure the HTTPS domain in the application linking prefixes.
• Configure the associated domain capability in iOS.
• Configure Android intent filters for the required domain and paths.
• Publish the required domain association files on the website.
• Rebuild and test the application on physical devices or emulators.

Do not assume that adding an HTTPS prefix in JavaScript alone completes Universal Link or Android App Link configuration.

7. Understanding Navigation Guards

7.1 What Is a Navigation Guard?

A navigation guard is a rule that determines whether a user should be allowed to access a screen or navigation flow. It is commonly used for authentication, permissions, subscription access, and role-based application features.

For example:

• A logged-out user should see the login or registration flow.
• A logged-in user should see the main application.
• An administrator-only screen should be available only to authorized administrators.
• A premium screen may require an active subscription.

7.2 Navigation Guards in React Navigation

React Navigation applications commonly implement access rules by conditionally defining available screens or groups based on application state. This is generally preferable to allowing every screen and manually redirecting users after each navigation attempt.

In React Navigation, conditional screen definitions can remove routes that are no longer available after authentication state changes. This also helps prevent users from returning to an obsolete login screen after signing in.

7.3 Authentication Versus Authorization

Important: Navigation guards improve the user experience, but they are not a security boundary on their own. The backend must independently verify authentication, permissions, and ownership for protected data and operations.

8. Authentication-Based Routing

8.1 What Is Authentication-Based Routing?

Authentication-based routing displays different sets of screens depending on the user's current authentication state.

A typical application has three states:

• Loading: The app is checking whether a saved session is valid.
• Unauthenticated: The user needs to log in or register.
• Authenticated: The user can access the main application screens.

Using a separate loading state prevents the application from briefly showing the login screen while an existing session is still being restored.

8.2 Typical Authentication Flow

1. The user opens the application.
2. The application checks secure storage for a saved session or token.
3. The application validates or restores the session using the appropriate authentication service.
4. While this check is in progress, a loading screen is displayed.
5. If the session is valid, authenticated screens become available.
6. If the session is missing or invalid, authentication screens become available.
7. After successful login, the authentication state changes and the navigator updates.
8. After logout, protected screens are removed and the login flow becomes available.

9. Building an Authentication Context

The following example demonstrates a simple authentication context. It illustrates navigation state management; a production application should connect the sign-in and session-restoration functions to a real authentication service.

9.1 Create AuthContext.js

import React, {
  createContext,
  useContext,
  useEffect,
  useState
} from 'react';

const AuthContext = createContext(null);

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);

  useEffect(() => {
    async function restoreSession() {
      try {
        // Replace with secure session restoration.
        // Validate the saved session with your auth service.
        setUser(null);
      } catch (error) {
        setUser(null);
      } finally {
        setIsLoading(false);
      }
    }

    restoreSession();
  }, []);

  async function signIn(credentials) {
    // Replace with a real authentication API request.
    // Never treat a non-empty password as proof of authentication.
    const authenticatedUser = await authenticateWithServer(credentials);
    setUser(authenticatedUser);
  }

  function signOut() {
    // Clear the server session/token and secure local credentials
    // as required by the authentication provider.
    setUser(null);
  }

  return (
    <AuthContext.Provider
      value={{
        user,
        isLoading,
        isSignedIn: Boolean(user),
        signIn,
        signOut
      }}
    >
      {children}
    </AuthContext.Provider>
  );
}

export function useAuth() {
  const context = useContext(AuthContext);

  if (!context) {
    throw new Error('useAuth must be used inside AuthProvider');
  }

  return context;
}

// Illustrative placeholder only.
// Implement this function with your authentication provider.
async function authenticateWithServer(credentials) {
  throw new Error('Connect authenticateWithServer to your auth API');
}

The authenticateWithServer function is intentionally a placeholder. Replace it with your real API or identity-provider integration. Do not use a hardcoded success response in a production login flow.

9.2 Understand the Context

• user stores the authenticated user's application state.
• isLoading indicates whether session restoration is still running.
• isSignedIn provides a convenient boolean for conditional rendering.
• signIn() should call the authentication provider and update the user only after successful authentication.
• signOut() should invalidate or clear the session as required by the provider.

10. Creating Authentication-Based Routes

10.1 Create the Root Navigator

This example uses a dynamic stack navigator. It renders either guest screens or authenticated screens according to the authentication context.

import React from 'react';
import { ActivityIndicator, View } from 'react-native';
import { createNativeStackNavigator } from '@react-navigation/native-stack';

import { useAuth } from './AuthContext';
import LoginScreen from './screens/LoginScreen';
import RegisterScreen from './screens/RegisterScreen';
import HomeScreen from './screens/HomeScreen';
import ProfileScreen from './screens/ProfileScreen';
import OrderHistoryScreen from './screens/OrderHistoryScreen';

const Stack = createNativeStackNavigator();

export default function RootNavigator() {
  const { isLoading, isSignedIn } = useAuth();

  if (isLoading) {
    return (
      <View style={{ flex: 1, justifyContent: 'center', alignItems: 'center' }}>
        <ActivityIndicator size="large" />
      </View>
    );
  }

  return (
    <Stack.Navigator>
      {isSignedIn ? (
        <>
          <Stack.Screen name="Home" component={HomeScreen} />
          <Stack.Screen name="Profile" component={ProfileScreen} />
          <Stack.Screen
            name="OrderHistory"
            component={OrderHistoryScreen}
          />
        
      ) : (
        <>
          <Stack.Screen name="Login" component={LoginScreen} />
          <Stack.Screen name="Register" component={RegisterScreen} />
        
      )}
    </Stack.Navigator>
  );
}

The example illustrates conditional routing. When the authentication state changes, React Navigation updates the available screens. Avoid manually navigating to Home immediately after changing the state in this pattern; let the navigator render the correct route set.

10.2 Wrap the App with Providers

import React from 'react';
import { NavigationContainer } from '@react-navigation/native';

import { AuthProvider } from './AuthContext';
import RootNavigator from './RootNavigator';

export default function App() {
  return (
    <AuthProvider>
      <NavigationContainer>
        <RootNavigator />
      </NavigationContainer>
    </AuthProvider>
  );
}

In a production implementation, the linking configuration can be passed to NavigationContainer alongside the authentication-aware navigator.

11. Implementing a Login Screen

A login screen collects credentials and submits them to an authentication service. The application should update its authentication state only after the service confirms a successful login.

import React, { useState } from 'react';
import {
  View,
  Text,
  TextInput,
  Button,
  Alert
} from 'react-native';

import { useAuth } from '../AuthContext';

export default function LoginScreen() {
  const { signIn } = useAuth();
  const [email, setEmail] = useState('');
  const [password, setPassword] = useState('');
  const [isSubmitting, setIsSubmitting] = useState(false);

  async function handleLogin() {
    if (!email.trim() || !password) {
      Alert.alert('Validation', 'Enter your email and password.');
      return;
    }

    try {
      setIsSubmitting(true);
      await signIn({ email: email.trim(), password });
    } catch (error) {
      Alert.alert('Login failed', 'Please check your credentials and try again.');
    } finally {
      setIsSubmitting(false);
    }
  }

  return (
    <View>
      <Text>Login</Text>
      <TextInput
        value={email}
        onChangeText={setEmail}
        placeholder="Email"
        autoCapitalize="none"
        keyboardType="email-address"
      />
      <TextInput
        value={password}
        onChangeText={setPassword}
        placeholder="Password"
        secureTextEntry
      />
      <Button
        title={isSubmitting ? 'Signing in...' : 'Sign In'}
        onPress={handleLogin}
        disabled={isSubmitting}
      />
    </View>
  );
}

Ensure the authentication service returns a valid authenticated user or session before the context changes to a signed-in state. Add production-grade input validation, rate limiting, error handling, and appropriate secure session management.

12. Implementing Logout

Logout should clear the current authentication state and invalidate the session with the authentication provider when applicable.

import React from 'react';
import { View, Text, Button } from 'react-native';
import { useAuth } from '../AuthContext';

export default function HomeScreen() {
  const { user, signOut } = useAuth();

  return (
    <View>
      <Text>Welcome to the application</Text>
      <Text>{user?.name ?? 'User'}</Text>
      <Button title="Logout" onPress={signOut} />
    </View>
  );
}

Once the context changes to an unauthenticated state, the navigator displays the guest screens and removes the authenticated route set. This helps prevent ordinary back navigation from returning to the previous authenticated screen.

13. Protecting Screens from Unauthorized Access

13.1 Protect Routes at the Navigator Level

Keep authenticated screens inside the authenticated route branch rather than registering every screen unconditionally. This reduces accidental navigation to protected screens from guest flows.

13.2 Validate Permissions

A logged-in user is not automatically authorized to perform every action. For example, an authenticated customer should not gain administrator privileges by modifying a route parameter.

function canManageUsers(user) {
  return user?.role === 'admin';
}

This helper can support UI decisions, but the server must also enforce the same permission for every sensitive request. Never trust a role value supplied by a deep link, a screen parameter, or a client-controlled field.

13.3 Handle Expired Sessions

If an API request reports that the session is invalid or expired, the application should use the authentication provider's session-expiration flow. Clear stale credentials, update authentication state, and return the user to the appropriate guest flow.

Do not assume that a token is valid merely because it exists in storage. Session validity depends on the provider's rules, expiration, revocation, and server-side checks.

14. Deep Linking to Protected Screens

A common scenario occurs when a user opens a link to a protected screen while signed out. For example:

myapp://orders

The application should not expose private order data before authentication. Instead, it should preserve or reconstruct the intended destination safely and open it after successful authentication.

14.1 Recommended Flow

1. The user opens a deep link to the order history screen.
2. React Navigation resolves the link to the intended route.
3. The authentication state is checked or restored.
4. If the user is signed out, the app presents the login flow.
5. The user signs in successfully.
6. The app allows navigation to the intended screen if the route is still valid and authorized.
7. The screen fetches private data from the backend using the authenticated session.

14.2 Authentication-Aware Linking Configuration

The following is a conceptual configuration for a dynamic navigator. Route names should match the screens defined in your application.

const linking = {
  prefixes: ['myapp://', 'https://app.example.com'],
  config: {
    screens: {
      Home: '',
      ProductDetails: 'products/:productId',
      Profile: 'profile',
      OrderHistory: 'orders'
    }
  }
};

When OrderHistory is not included in the unauthenticated route set, the app must provide a deliberate strategy for handling a link to that route while signed out. React Navigation's authentication-flow guidance discusses retaining unhandled deep links; some relevant route-name-change behavior APIs are marked experimental, so verify their status for the version in your project.

For a simpler implementation, save only an allowlisted intended destination, complete authentication, and then resolve the destination through your navigation flow. Do not navigate to arbitrary route names taken from an external URL.

14.3 Avoid Unsafe Redirects

• Allow only known route names and supported parameters.
• Validate IDs and other URL parameters before using them.
• Do not accept arbitrary redirect URLs from untrusted input.
• Require authentication and authorization before fetching private content.
• Handle deleted resources, expired promotions, and invalid identifiers gracefully.

15. Testing Deep Links

15.1 Test a Custom Scheme

After configuring and installing a compatible application build, use a deep-link testing tool or the platform's command-line utilities to open a sample URL.

Example URL:

myapp://products/101

15.2 Test on Android

For a custom scheme configured in the Android manifest, a command similar to the following can be used on a connected device or emulator:

adb shell am start -W -a android.intent.action.VIEW \
  -d "myapp://products/101"

The Android manifest must contain an appropriate intent filter for the scheme. Verified HTTPS links require the relevant host configuration and domain association.

15.3 Test on iOS

Use the iOS Simulator's URL-opening tools or the appropriate development tooling to open the configured URL. Confirm that the app's native configuration supports the scheme or Universal Link being tested.

15.4 Test Authentication Scenarios

• Open a public link when signed out.
• Open a protected link when signed out.
• Open a protected link when signed in.
• Sign in after arriving from a protected link.
• Log out while viewing a protected screen.
• Open a link containing an invalid identifier.
• Test when the app is closed and when it is already running.
• Test expired sessions and failed API requests.

16. Common Problems and Troubleshooting

17. Best Practices

• Use React Navigation's built-in linking integration instead of implementing all URL routing manually.
• Keep linking configuration consistent with the navigator hierarchy.
• Use stable, documented URL paths for screens intended to be shared externally.
• Use HTTPS Universal Links and Android App Links where verified domain handling is appropriate.
• Represent loading, signed-out, and signed-in states separately.
• Restore sessions securely and validate them with the authentication provider.
• Conditionally register routes based on authentication state.
• Keep authentication and authorization rules separate.
• Validate all deep-link parameters and handle unknown routes gracefully.
• Do not store passwords or sensitive tokens in ordinary unencrypted storage.
• Use an appropriate secure-storage solution and follow the authentication provider's token-handling guidance.
• Enforce permissions on the backend, regardless of what screens are visible in the app.
• Test cold starts, warm starts, login, logout, expired sessions, and invalid links.
• Keep private information out of URL parameters because URLs may be logged, shared, or exposed to other systems.

18. Mini Project: Secure Product and Order Navigation

Project Overview

Create a React Native shopping application that supports deep links to products and protects user order history through authentication-based routing.

Project Requirements

• Create Home, Product Details, Login, Register, Profile, and Order History screens.
• Configure custom-scheme deep links for product details.
• Map product IDs from URLs into route parameters.
• Allow guest users to browse public product information.
• Require authentication for Profile and Order History screens.
• Restore an existing session when the application starts.
• Provide logout functionality.
• Handle invalid product IDs and missing resources.
• Test the application with the app closed and already running.

Suggested Test Cases

19. Exercises

1. Explain the difference between a custom URL scheme and an HTTPS Universal Link.
2. Configure a deep link for a Product Details screen that accepts a product ID.
3. Build a loading state that waits for authentication restoration.
4. Create separate guest and authenticated route sets.
5. Add a logout button that updates the authentication state.
6. Protect an Order History screen from guest access.
7. Design a safe approach for opening a protected deep link after login.
8. Explain why frontend navigation guards do not replace backend authorization.
9. Test invalid URL parameters and implement an appropriate error screen.
10. Document how to configure and test custom schemes on Android and iOS.

20. Interview Questions and Answers

Q1. What is deep linking in React Native?

Deep linking allows an external URL to open a specific screen in a React Native application.

Q2. What is a custom URL scheme?

It is an application-specific URL prefix, such as myapp://, configured so the operating system can direct matching links to the app.

Q3. What is the difference between a deep link and a normal navigation action?

A normal navigation action usually originates inside the app. A deep link begins with an external URL and resolves to a route inside the application.

Q4. What is the purpose of the linking prop?

The linking configuration allows React Navigation to interpret incoming URLs and map paths to screens and parameters.

Q5. What is a navigation guard?

A navigation guard is a rule that controls whether a route or feature should be available based on authentication, permissions, or another application condition.

Q6. What is authentication-based routing?

It is a navigation pattern that displays different route sets depending on whether a user is authenticated.

Q7. What is the difference between authentication and authorization?

Authentication verifies identity, while authorization determines which resources or actions that identity is allowed to access.

Q8. Why is a loading state necessary during authentication restoration?

It prevents the application from displaying the wrong route set while the app is still checking for an existing session.

Q9. Why use conditional screen definitions?

They allow the navigator to expose only the screens relevant to the current authentication state and remove screens that are no longer available.

Q10. What should happen after successful login?

The authentication state should update, causing the authenticated route set to become available. In a conditional-routing setup, manual navigation to the home screen is generally unnecessary.

Q11. What should happen after logout?

The app should clear or invalidate the session as required, update the authentication state, and remove protected routes from the active navigation structure.

Q12. How can a deep link pass a parameter?

A path such as products/:productId can parse a URL such as myapp://products/101 and supply the product ID as a route parameter.

Q13. How should a protected deep link work for a logged-out user?

The application should require authentication before showing private content and safely preserve or reconstruct the intended destination so it can be opened after login.

Q14. What is an Android App Link?

It is a verified HTTPS link associated with an Android application through domain association and native app configuration.

Q15. What is an iOS Universal Link?

It is an HTTPS link associated with an iOS application using the relevant domain association and application configuration.

Q16. Are navigation guards enough to secure an application?

No. The backend must independently validate authentication and authorization for protected API operations and data.

Q17. Why validate deep-link parameters?

External URLs can contain malformed, missing, or unexpected values. Validation prevents invalid input from causing crashes or unsafe requests.

Q18. What is the difference between a cold start and a warm start?

A cold start occurs when the application is not running before a link is opened. A warm start occurs when the app is already running and receives a new link.

Q19. How should expired sessions be handled?

The app should follow the authentication provider's expiration flow, clear stale session state, and return the user to an appropriate authentication route.

Q20. What are common deep-linking problems?

Common issues include incorrect URL prefixes, missing native configuration, mismatched route paths, incomplete domain verification, and invalid route parameters.

21. Quick Revision Checklist

• Deep linking opens a specific application screen from a URL.
• Custom schemes and verified HTTPS links require different platform configurations.
• React Navigation supports URL-to-screen mapping through its linking integration.
• Route parameters from URLs must be validated.
• Navigation guards manage which routes are available to users.
• Authentication identifies the user; authorization determines permissions.
• Session restoration should finish before choosing the final route set.
• Conditional routing helps remove obsolete login or protected routes.
• Protected deep links should require authentication before private content is displayed.
• Backend services must enforce access control independently of the mobile UI.
• Test deep links on both cold and warm starts.

22. Conclusion

Deep linking, navigation guards, and authentication-based routing are important techniques for building reliable React Native applications. Deep linking provides direct access to specific screens, navigation guards help control route availability, and authentication-based routing separates guest and signed-in experiences.

A robust implementation combines correct React Navigation configuration, secure session restoration, validated URL parameters, appropriate handling of protected destinations, and backend authorization. Together, these practices improve usability while keeping private application data protected.

23. Additional Learning Resources

• React Navigation: Deep Linking
• React Navigation: Configuring Links
• React Navigation: Authentication Flows
• React Native: Linking API
• React Native Training Course
• Register for a Course Demo
• JustAcademy Official Website